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Abstract 

Decisions on which classes to refactor are fraught 
with difficulty. The problem of identifying candidate 
classes becomes acute when confronted with large sys- 
tems comprising hundreds or thousands of classes. In 
this paper, we describe a metric by which key classes, 
and hence candidates for refactoring, can be identi- 
fied. Measures quantifying the usage of two forms of 
coupling, inheritance and aggregation, together with 
two other class features (number of methods and at- 
tributes ) were extracted from the source code of three 
large Java systems. Our research shows that met- 
rics from other research domains can be adapted to 
the software engineering process. Substantial differ- 
ences were found between each of the systems in terms 
of the key classes identified and hence opportunities 
for refactoring those classes varied between those sys- 
tems. 



1 Introduction 

The term refactoring refers to a technique for im- 
proving code quality by making changes to the internal 
structure of the software without changing its exter- 
nal behaviour. Refactoring can be used to improve 
software design by, for example, moving code between 
classes, extracting code into new methods or classes 
or altering the position of classes in an inheritance hi- 
erarchy. Refactoring therefore leads the programmer 
to work more deeply on understanding what the code 
does and is thus an aid to maintenance and reuse [J]- 

The potential benefits of carrying out refactoring 
are reduced duplication of code, improved readabil- 
ity, faster development and fewer bugs. Whilst there 



has been considerable interest in refactoring princi- 
ples, relatively little research seems to have focused 
on the identification of candidate classes for the refac- 
toring process itself. 

Extreme programming (XP) practitioners use 
refactoring to remove duplication whenever program 
features are added. Beck's advice is that program- 
mers should not "refactor on speculation . . . refactor 
when the system asks you to" [Q. Whilst this advice 
may be appropriate for XP projects, refactoring of key 
classes may also be required when developing libraries 
for other programmers to use or when developing soft- 
ware in large teams. 

We conjecture that there are certain classes in ev- 
ery OO system which are of such importance (in terms 
of the features they possess) that they should be a 
priority for refactoring effort. In this paper we show 
how these classes may be identified through two count- 
able measures (number of methods and number of 
attributes) and through a Web-based graph metric 
which identifies the extent of each class' coupling via 
inheritance and aggregation. The potential gain (PG) 
metric was first used as a means of identifying key web 
pages in a Web search and navigation system. The po- 
tential gain has been used here to rank classes in terms 
of their coupling patterns. By ranking classes accord- 
ing to all these features, candidate key classes can be 
identified. 



2 Motivation and related work 

The motivation for the research in this paper stems 
from a number of sources. Firstly, developers will 
inevitably want to quickly identify which classes are 
key to the system as a whole. This may be because 
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they wish to avoid applying refactoring effort to such 
classes, and the associated problems of re-testing. Al- 
ternatively, it may be that those classes are the ones 
which need to be maintained most rigorously because 
they are key classes and exert considerable influence 
in the system as a whole. The research in this paper 
allows those classes to be identified more easily. 

Another motivation for the work in this paper stems 
from a lack of research into refactoring decision crite- 
ria. The basis on which a particular class (or refac- 
toring) should be chosen is not well understood or 
documented. We view it as a fruitful and interest- 
ing research topic. While there has been plenty of 
evidence for the benefits of refactoring, exactly what 
to refactor (and when) is still an open issue. Availabil- 
ity of tool support for refactoring (although improving 
significantly) seems dwarfed by current progress and 
thinking in the area. Our research is an attempt to 
highlight the criteria by which refactoring effort can 
be initially chanelled. 

A further motivation for the research is to iden- 
tify whether Java classes exhibit similar properties to 
their C++ counterparts. This builds on earlier work 
[3], where high-level class metrics were collected from 
the Unified Modelling Language (UML) ^7] documen- 
tation of five large C++ systems, two of which were 
libraries. Two conjectures were investigated to deter- 
mine features of key classes in a system and to inves- 
tigate any differences between library-based systems 
and other systems in terms of coupling. Key classes in 
the three application-based systems tended to contain 
significant amounts of aggregation, large numbers of 
methods, attributes and associations, but little inheri- 
tance. No consistent, identifiable key features could be 
found in the two library-based systems; both showed 
a distinct lack of any form of coupling (including in- 
heritance) other than through the C++ friend facility. 

In terms of seminal refactoring literature, the PhD. 
work of Opdyke |15| describes a number of software 
refactorings. This thesis spawned a large amount of 
research in the subject. Opdyke and Johnson de- 
scribe a study in which they illustrate how to create 
abstract superclasses from other classes by refactoring. 
They decompose the operation into a set of refactor- 
ing steps, and provide examples. They also discuss a 
technique that can automate these steps making the 
process of refactoring much easier. In Johnson and 
Opdyke |SJ, some common refactorings based on ag- 
gregation are reported, including how to convert from 
inheritance to aggregation and how to reorganize an 
aggregate/component hierarchy. They also describe 
how to refine aggregations by moving variables and 



functions between aggregate and component classes, 
and how to move variables and functions within in- 
heritance hierarchies. A text by Fowler 0j describes 
seventy-two types of refactoring and illustrates each 
type with examples and UML notation. 

Recent empirical work in the refactoring area and 
its automation is found in [T§|, where 14 000 lines 
of code were transformed automatically where they 
would otherwise have had to be coded by hand. In 
Najjar et al. H2|, the opportunities, benefits and prob- 
lems of refactoring class constructors across a sample 
of classes from five Java systems were investigated. 
The refactoring used, replacing multiple constructors 
with creation methods was applied to each of a set of 
classes containing three or more constructors. 

3 Empirical Evaluation 

We address the empirical evaluation through a sin- 
gle conjecture, related to key classes as follows: 

CI: In the type of systems investigated, a certain 
number of classes have higher numbers of meth- 
ods, attributes, aggregation relationships and 
subclasses than other classes in the same type of 
system. These classes will, typically, be found 
towards the root of an inheritance hierarchy so 
that subclasses may take advantage of the large 
functionality and features they offer. 

This is what we believe characterises a key class. 
We accept that there are many other forms of cou- 
pling which are equally worthy of investigation, and 
hence we do not claim our criteria to be definitive. In 
Section 5, we justify our choice of criteria by reference 
to several core refactorings. 

3.1 Potential Gain 

The potential gain metric was originally developed 
to aid the selection of pages allowing for future navi- 
gation of Web sites. By considering the number and 
length of all possible paths from a given node, an es- 
timate of the utility or connectivity of a node could 
be established. If the density of the neighbourhood of 
some node in a graph is high, then many nodes are 
connected via short paths and the PG of that node is 
also higher. In complex systems, the lengths of these 
paths reflect the likely influence on connected nodes 
or classes. 

As part of this research, a system called AutoCode 
was developed for indexing Java source code. Au- 
toCode works by using a custom doclet which extends 



the Javadoc program and allows easy access to the 
code structure. We used the AutoCode system to gen- 
erate graphs for each of five coupling types - Inher- 
itance, Aggregation, Interface, Parameter Type and 
Return Type. Previous work described features of 
these graphs 2U|. This paper describes new work in- 
vestigating the utility of the potential gain metric for 
analysing key classes using the Inheritance and Aggre- 
gation graphs. 

The Potential Gain, PG(c), of a class, c, is defined 
as the sum for all lengths (or depths) of the product of 
the fraction of all possible coupling paths which are of 
length d and a discounting function f(d). This gives 
a measure of the number of objects with which an 
instance of the class might potentially interact. For 
example, in the case of inheritance, the potential gain 
metric reflects both the breadth and depth of a hier- 
archy. A formal definition of potential gain is given in 
appendix A. 

Related to class coupling, the PG metric gives an 
indication of the inter-connectivity of a class with 
other classes. The type of connectivity can be defined 
in the software which extracts (in the case of this re- 
search) the aggregation and inheritance relationships. 
For example, a high PG value for a class at a point 
in the inheritance hierarchy means that the class has 
a relatively large number of descendants. A very low 
value indicates that it is a leaf node - in other words, 
it has no subclasses. 

Although the mathematics behind the potential 
gain is non-trivial, computation of the values is effi- 
cient. For example, once an appropriate graph struc- 
ture had been obtained, PG values were computed for 
all 6 000 classes in the JDK in less than five seconds 
on a desktop-class PC. 

3.2 Data collected 

Data was collected from three large Java systems. 
Those systems were chosen since they were the sub- 
ject of previous research. The three systems chosen are 
used extensively by developers in industrial settings. 
In keeping with previous work on CH — h systems, we 
investigate two applications and one library-based sys- 
tem. As well as identifying key classes, previous work 
also found distinct differences between these two types 
of system, together with a lack of use of inheritance 
in all types of system. While this latter feature is not 
likely to be the case in a Java setting (because of the 
emphasis on inheritance in Java), our belief is that 
Java classes will exhibit some contradicting features 
across the systems. The three systems investigated 
were: 



1. JDK - The core Java class libraries shipped with 
the Java Developers Kit (JDK) which provide im- 
plementations of common functions required for 
many programs. This contains I 400 000 lines of 
code spread over 6 000 classes. 

2. Tomcat is a servlet container used in the official 
reference implementation for Java Servlets and 
JavaServer Pages. The source code for Jakarta 
Tomcat contains 150 000 lines spread over 370 
classes. 

3. Ant is a Java-based build tool and behaves in a 
similar way to make but uses XML-based configu- 
ration files defining various tasks to be executed. 
The source code for Apache Ant contains 145 000 
lines of code spread over 500 classes. 

3.2.1 Metrics collected 

The following data was collected automatically, using 
the same software which produced values for the PG 
metric. 

1. The Number of Methods in a class, including 
public, protected and private member functions. 

2. The Number of Class Attributes, including pub- 
lic, protected and private declarations. 

3. The Depth or level of a class in an inheritance 
hierarchy where a zero value represents the root. 
The metric is based on the Depth of Inheritance 
Tree metric of Chidamber and Kemerer [2] . 



4 Data Analysis 

4.1 Summary Data 

Table Ogives the summary data for the three sys- 
tems, in terms of maximum and median values for the 
three metrics collected. The JDK shows the largest 
maximum values for all three metrics. The class 
with 254 methods is j ava . awt . Component with 80 
attributes and is found at level 1 in the JDK inher- 
itance hierarchy. A Component is any object having 
a graphical representation and that can interact with 
the user. The JDK class with 329 attributes is class 
xalan. templates. Constants with zero methods and 
again, was found at depth 1. Two classes PI0RB and 
NS0RB reside at the lowest depth of the JDK library 
(depth 8) with 41 and 2 methods, respectively. 



The Tomcat and Ant systems are comparable in 
terms of number of methods and attributes. The Tom- 
cat class with 168 methods is StandardContext, with 
49 attributes and is found at depth 2. The class with 
57 attributes was JspC with 45 methods, found at 
depth 1. This class provides the shell for the jspc 
compiler. 

The Ant class with 89 methods is Project, 
found at depth 1 with 33 attributes. The class, 
CBZip2InputStream with 47 attributes has 31 meth- 
ods (see Tabled and is a possible candidate for refac- 
toring. Visual inspection of both classes revealed two 
bad smells - Primitive Obsession and Long Methods 
0]. In our analysis we have viewed basic system types, 
such as String as primitive. 





Metric 


Max 


Median 


JDK 


Methods 


254 


3 




Attributes 


329 


3 




Depth 


8 


2 


Tomcat 


Methods 


168 


5 




Attributes 


57 


2 




Depth 


4 


1 


Ant 


Methods 


89 


4 




Attributes 


47 


2 




Depth 


6 


2 



Table 1: Summary data for all three systems 



4.2 Investigating Conjecture CI 

Identification of key classes has significant impli- 
cations for refactoring and ultimately, maintainabil- 
ity. If such classes contain significant functionality and 
are coupled to numerous other classes, then modifica- 
tion of those classes needs to be made with particular 
care. This is particularly important if they are found 
at shallow levels in an inheritance hierarchy (i.e., a 
low depth) since all subclasses need to be considered 
if any change is made to that class. 

From the summary data and the previous discus- 
sion, it appears that in each of the three systems there 
are classes with large numbers of methods and at- 
tributes. Conjecture CI attempts to clarify the extent 
to which combinations of all features, including aggre- 
gation, are found in the same classes. By aggregation 
relationships, we mean classes which either use a large 
number of other classes or are used by a similarly large 
number of other classes (or both). Hereafter, we will 
call these two types of aggregation normal aggregation 
and reverse aggregation, respectively. 



4.2.1 The JDK library 

Table [21 shows, for the JDK system, the numbers of 
methods and attributes and the depths of inheritance 
for the top fifteen classes when ranked in descending 
order according to their reverse aggregation PC value. 
A high reverse aggregation PG value implies that a 
lot of classes use the class in question. Classes such 
as PageAttributes . MediaType, Color and Charac- 
ter .UnicodeBlock are used in constant (static final) 
declarations and are often self-referencing. 

Two of the classes identified in Table 
have zero attributes and two have zero meth- 
ods. The maximum depth in the inheritance 
hierarchy was 3 for two classes - Vector and 
j avax . print . attribute . standard . MediaSizeName. 
The presence of Hashtable and Vector as commonly 
used objects suggests that the Collections framework 
introduced in JDK 1.2 has not been fully adopted 
within the JDK. 

The top fifteen classes were then ranked in de- 
scending order according to their normal aggregation 
PG value. These fifteen classes were then compared 
with the reverse aggregation classes in Table |5] Eight 
classes were found to coincide with the previous fifteen 
found. Table names these classes, together with the 
position they occupied in Table 

The classes in Table are mostly self-referencing 
classes with many static references. For example, 
PageAttributes .MediaType contains a self-reference 
for each paper format (e.g. A4, US Letter, etc.). Such 
classes induce high PG values. A similar effect was ob- 
served with Web-search metrics. Lempel and Moran 
showed that metrics such as HITS and PageR- 
ank |16j can be influenced by a phenomenon called 
the Tightly Knit Community (TKC) Effect 12 . The 
TKC effect has a negative influence on search results 
when small groups of pages are heavily interlinked. In 
the analysis of program code, the TKC effect is useful 
for identifying classes or networks of classes which are 
tightly bound and where functionality is impossible 
to extract. This is made possible by considering more 
than one metric in the analysis. 

A high normal aggregation PG value would imply 
that an instance of this class will make many references 
to objects which, in turn, make many references to 
other objects. Modifying or refactoring class with high 
normal aggregation PG values require careful thought 
and preparation, since many other classes may be af- 
fected by such a change. 

By considering those classes which score highly on 
both metrics, we can eliminate those classes which are 
self-referencing. The results of eliminating such classes 
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Table 2: The fifteen classes with the highest reverse aggregation PG values: JDK 



Classname 


Reverse PG 


PG 


Page Attributes . MediaType 


1 


1 


Char acter.UnicodeB lock 


3 


2 


HTML.Attribute 


4 


3 


HTML. Tag 


5 


4 


MediaSizeName 


6 


5 


Color 


7 


14 


CSS.Attribute 
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6 


AccessibleRole 


10 


7 



Table 3: Eight class appear in the top fifteen classes 
for both normal and reverse aggregation PG values: 
JDK 



leave String, Object, Hashtable, Vector and Class 
clearly identifiable as extensively used, key classes. 

Table 0| shows the top fifteen classes when ranked 
on descending inheritance PG values. It is interesting 
to note that only one class from Table |3] appears in 
the top fifteen JDK classes from Table 0] This class 
was java.lang. Object, as might be expected; a high 
inheritance PG value implies that a class has many 
subclasses. 

We note that the JDK class j ava . awt . Component 
with 254 methods (Tabled was ranked 25th in terms 
of reverse aggregation, 26th by aggregation and 5th 
by inheritance. This places the class in the top 1% 
for all metrics. We would therefore consider this a key 
class. Additionally, it may be considered a Large Class 
0] and hence a candidate for refactoring via Extract 
Class or Extract Subclass because of this "bad smell" . 

Finally, it is also noticeable that six classes with 
the highest reverse aggregation PG values have three 
or more constructors. This would make those classes 
eligible for refactoring by replacing multiple construc- 
tors with creation methods as suggested by Kerievsky 



and empirically investigated by Najjar et al. |1UI 114) . 

Considering conjecture CI, the classes most often 
used in aggregation relationships do not necessarily 
contain the highest numbers of methods or attributes. 
Neither is the nature of those classes suitable for use by 
subclasses. For example, String and Class are final 
and Hashtable and Vector are themselves subclasses 
of Dictionary and AbstractList, respectively. 

4.2.2 The Tomcat system 

Table [3] shows, for the Tomcat system, the numbers of 
methods, fields and constructors and the depth in the 
inheritance hierarchy, for the top fifteen classes when 
ranked in descending order by their reverse aggrega- 
tion PG values. 

From Table [5] it is interesting that the mean in- 
heritance depth of the fifteen classes is considerably 
smaller than in the JDK. Only one class, Node. Root 
extends any class other than j ava . lang . Obj ect, com- 
pared with six in the JDK. It is also interesting to note 
that no class in the top fifteen when ranked by inher- 
itance is present in either of the lists for top classes 
when ranked by normal or reverse aggregation PG val- 
ues. 
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Table 6: Seven class appear in the top fifteen classes 
for both normal and reverse aggregation PG values: 
Tomcat 
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Table 4: The fifteen classes with the highest inheritance PG values: JDK 



Classname 


Methods 


Attributes 


Constructors 


Depth 
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15 
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Table 5: The fifteen classes with the highest reverse aggregation PG values: Tomcat 



We would expect the depth values for both Tomcat 
and Ant to be smaller than those for the JDK, and 
this is borne out in the values from Table [SJ A con- 
tributing factor to this is the role that the JDK class 
java. lang. Object plays - every class in the JDK ex- 
tends class java. lang. Object by default. 

The top fifteen classes were then extracted for nor- 
mal aggregation PG values. Table El shows that six 
of these top fifteen could also be found in the fifteen 
reverse aggregation values from Table [S] 

We note that the class JspC with 57 attributes 
(see Table did not figure in cither the highest 
normal or reverse aggregation PG values. Inspec- 
tion of the raw data revealed it to be ranked 172 
(reverse aggregation) and 73 (normal aggregation) 
from 321 classes analysed. Visual inspection revealed 
that most attributes of the class were Strings and 
ints. Also, the class with 168 methods (see Tabled, 
catalina. core . StandardContext, has 49 attributes 



and is ranked 37th by reverse aggregation PG, 14th by 
aggregation PG and 41st by inheritance. Although it 
does not fit in the top fifteen by reverse aggregation, 
it may be considered a candidate class for refactoring. 
The most obvious refactorings relate to a bad smell - 
namely Primitive Obsession @]. 

With regards to conjecture CI, it is not true to say 
that classes with substantial amounts of aggregation 
(either normal or reverse), or indeed, with substantial 
amounts of methods and/or attributes tend to have 
the highest number of descendents (i.e., tend to be 
found near the root of an inheritance hierarchy) . 

With respect to refactoring of constructors, we note 
that only two classes of those listed in Table have 
three or more constructors. This would imply less 
scope for refactoring by replacing multiple construc- 
tors with creation methods in this system. This con- 
strasts with the JDK where there were six such classes. 
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Table 7: The fifteen classes with the highest reverse aggregation PG values: Ant 



4.2.3 The Ant system 

Table shows values the the fifteen highest reverse 
aggregation values. None of these classes were in the 
top fifteen classes when sorted by aggregation PG val- 
ues. Only one class, Task was present in the top fif- 
teen when sorted by inheritance PG values. This class 
was ranked 30th in the aggregation list - just outside 
the top 1%. One possible explanation for the lack of 
overlap is that the inheritance hierarchy in Ant centers 
around the Task and ProjectComponent classes. This 
means that the other classes in Ant depend more upon 
inheritance and less upon aggregation and delegation. 

One hypothesis to explain this behaviour is that ag- 
gregation is used as a surrogate for inheritance. The 
results from the JDK and Tomcat systems, where 
there was very little overlap between inheritance and 
aggregation PG values, and in particular from the Ant 
system, suggests that this may be the case. The hy- 
pothesis that delegation is used as a surrogate for mul- 
tiple inheritance fits well with the observation that 
the distribution of interfaces follows a power-law [30| . 
Whilst many classes implement a few interfaces, a few 
classes implement a large number of interfaces. Those 
that do, tend to delegate the responsibility for the 
methods of these interfaces to members of the same 
interface. 

In the Ant system, we would consider the top ten 
classes found by ordering reverse aggregation PG value 
to be key classes. Of these, Project with 89 methods 
and 33 attributes stands out as Large Class and a pos- 
sible candidate for refactoring. Hence, conjecture CI 
would seem to be supported for the Ant system. 

With regards to refactoring, only one class of those 
in Table [3 has three constructors. The rest are ineligi- 
ble for refactoring by replacing multiple constructors 



with creation methods. Together with the result for 
Tomcat, this implies a significant difference between 
libraries and application systems; namely key classes 
in library systems tend to have a greater number of 
constructors. 



5 Meta-analysis of refactorings 

The focus of the research in this paper has been 
to identify candidate classes for refactoring - i.e. key 
classes. We have chosen specific properties to identify 
such classes. We now need to justify why, for example, 
we chose aggregation and inheritance relationships, to- 
gether with the number of methods and attributes as 
those features (as opposed to any other class features) . 

To illustrate why, and as part of the research herein, 
a dependency diagram showing the relationships be- 
tween the seventy-two refactorings outlined in Fowler 
et al. @] was developed. From this meta-analysis 
emerged various core refactorings. By core refactor- 
ings, we mean those refactorings upon which a large 
number of other refactorings depend and are required 
in each of those refactorings. The three most impor- 
tant of these, in terms of the number of refactorings de- 
pendent on them, as established by the meta-analysis, 
are: 

1. Extract Method - which should be performed 
when the code body of a method is getting too 
long. 

2. Move Field - which should be performed when 
that field is being used by another class more than 
by the class in which it is defined. 



3. Move Method - which should be performed 
whenever a method is using features of another 
class more than those in which it is defined. 

For both of the latter two core refactorings, and 
to a lesser extent extract method, aggregation plays 
a central role. If we wish to move a field, then the 
type of that field must be considered; it may be that 
of another class. If we want to move a method from 
one class to another, then all types of coupling in that 
method (including inheritance and aggregation) must 
be considered; removing the coupling from the source 
class may simplify it, but their loss needs to be re- 
placed with appropriate code. Analysis of the me- 
chanics of the two refactorings reveals inheritance to 
play a large role, in keeping with many other refactor- 
ings. For example, the Move Field refactoring requires 
as part of its mechanics that if the field is not declared 
as private, then all subclasses need to be checked for 
references to that field. The Move Method refactoring 
requires all subclasses and superclasses to be checked 
for references to that method. 

We also believe that classes with large numbers of 
methods and attributes are likely to require applica- 
tion of these two refactorings at some point. More- 
over, we refer to two common bad smells in classes 
identified in this paper from the key classes chosen - 
that of Large Class characterised by too many meth- 
ods and Primitive Obsession characterized by overuse 
of primitive attributes and system classes. We there- 
fore justify our choice of criteria for selection of key 
classes on this basis of these arguments. 



6 Conclusions and Future Research 

In this paper, we have described a technique by 
which key classes can be identified from three Java 
systems. A metric, potential gain, was adapted from 
use in Web search and navigation problems to evalu- 
ate the dependence which the system places on var- 
ious classes. By computing values for potential gain 
on graphs for two forms of coupling, namely, inheri- 
tance and aggregation, we were able to identify can- 
didate key classes. By combining these results with 
two other class features (number of class methods and 
class attributes) we were able to further isolate classes 
in possible need of refactoring. 

Four principal results emerged from the research. 
Firstly, that metrics from other research domains can 
be adapted to aid developers and researchers in the 
refactoring process. 



Secondly, there are substantial differences between 
each of the three systems investigated. The JDK sys- 
tem has key classes with more constructors. This is re- 
flected in the mean number of constructors for classes 
within these systems - 1.242 for JDK against 1.073 for 
Ant and 1.069 for Tomcat. 

Thirdly, there is also evidence to suggest that only 
the Ant system exhibits the expected properties of key 
classes according to conjecture CI. We therefore reject 
the hypothesis that key classes are consistently found 
at the base of inheritance hierarchies. 

Finally, the analysis supports previous work on 
power-laws, which suggested that interfaces were com- 
monly used as a surrogate for multiple implementation 
inheritance. 

Future work will focus on two areas. Firstly, ex- 
panding the scope of what a key class is. The PG met- 
ric will be used to extract details relating to method 
parameters, method return types and interfaces. A 
second area of future research will investigate the po- 
tential for the key classes identified in this paper to be 
refactored. The research thus represents a first step 
in establishing the features of classes most eligible for 
refactoring. 
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A Potential Gain 

Formally, if the fraction of all possible paths in a 
directed graph, G = (N, E) , to a depth, d > 0, which 
start from a node, n £ N is given by 



R d {n) 



E 



R d -i{v) 



yeOut(n) 



I2j£N R d-l{j) 



where R — 1 and N is the set of nodes, E is the set of 
edges and Out(i) — {j\(i,j) € E}, then the Potential 
Gain of n is given by 



Pg(n) = J2 Rk(x)f(x) 



k=l 

The constant, Rq = 1, whilst not strictly accurate, is 
used to to ensure that log Pg(n) > holds for all n. 
Two reasonable functions for f{d) are the reciprocal 
function: 

f(d) = reciprocal(d) — 1/d 
and the exponential decay function: 
f(d) = decayed) = 7 d 

where < 7 < 1 is a constant. 

The original justification for the use of these mea- 
sures in the context of Web search was based on the 
assumption that the utility of browsing a page dimin- 
ishes with the distance of the page from the starting 
URL. This assumption is consistent with experiments 
carried out on real Web data (BJEHj and with studies 
showing that the probability of a user following a path 
of length n decreases as n increases |18| . 

The justification for these measures in the context 
of coupling is based on the fact that the influence that 



two classes have on each other diminishes as the dis- 
tance (in terms of coupling) increases. This is a fea- 
tures of many patterns - such as Mediator and Facade 
5 which reduce communication and dependencies by 
introducing "middle-men" . 

The PG metric was collected automatically for each 
type of coupling for each class in the three systems, 
and the reciprocal function was used to compute the 
potential gain values. 



